1. 현행 시스템 파악 절차

시스템 구성 파악 : 현행 시스템의 구성은 조직의 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술
시스템 기능 파악 : 현행 시스템의 기능은 단위 업무 시스템이 현재 제공하는 기능들을 주요 기능과 하부 기능, 세부 기능으로 구분하여 계층형으로 표시
시스템 인터페이스 파악 : 현행 시스템의 인터페이스에는 단위 업무 시스템 간에 주고받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시
아키텍처 구성 파악 : 현행 시스템의 아키텍처 구성은 기간 업무 수행에 어떠한 기술 요소들이 사용되는지 최상위 수준에서 계층별로 표현한 아키텍처 구성도로 작성
소프트웨어 구성 파악 : 소프트웨어 구성에는 단위 업무 시스템별로 업무 처리를 위해 설치되어 있는 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시
하드웨어 구성 파악 : 하드웨어 구성에는 단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량, 그리고 이중화의 적용 여부를 명시
네트워크 구성 파악 : 네트워크 구성은 업무 시스템들의 네트워크 구성을 파악할 수 있도록 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성

2. 개발 기술 환경

운영체제(OS)
- 컴퓨터 시스템의 자원들을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어
- 고려사항 : 가용성, 성능, 기술 지원, 구축 비용, 주변 기기
데이터베이스 관리 시스템(DBMS)
- 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고, 데이터베이스를 관리해 주는 소프트웨어
- 고려사항 : 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용
웹 애플리케이션 서버(WAS)
- 정적인 콘텐츠 처리를 하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
- 고려사항 : 가용성, 성능, 기술 지원, 구축 비용
오픈 소스
- 누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 공개한 것으로 오픈 소스 라이선스를 만족하는 소프트웨어
- 고려사항 : 라이선스의 종류, 사용자 수, 기술의 지속 가능성

3. 요구사항 유형

기능 요구사항 : 시스템이 갖춰야할 필수적인 기능에 대한 요구사항
비기능 요구사항 : 필수 기능 외의 품질이나 제약사항에 관한 요구사항
사용자 요구사항 : 사용자 관점에서 본 시스템이 제공해야 할 요구사항
시스템 요구사항 : 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항

4. 요구사항 개발 프로세스

요구사항 도출 : 시스템, 사용자, 그리고 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정
- 주요 기법 : 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스
요구사항 분석 : 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
- 비용과 일정에 대한 제약 설정, 타당성 조사
요구사항 명세 : 요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화
요구사항 확인 : 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토

5. 요구사항 분석 기법

개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호한 부분을 걸러내기 위한 방법
요구사항 분류: 요구사항을 명확히 확인할 수 있도록 요구사항을 분류함
개념 모델링
모델 : 요구사항을 보다 쉽게 이해할 수 있도록 현실 세계의 상황을 단순화하여 개념적으로 표현한 것
모델링 : 모델을 만드는 과정
개념 모델 종류 : 유스케이스 다이어그램, 데이터 흐름 모델, 상태 모델, 목표기반 모델, 사용자 인터액션, 객체 모델, 데이터 모델 등
요구사항 할당 : 요구사항을 만족시키기 위한 구성 요소를 식별하는 것
요구사항 협상 : 요구사항이 서로 충돌될 경우 이를 적절히 해결하는 과정
정형 분석: 구문(Syntax)과 의미(Semantics)를 갖는 정형화된 언어를 이용해 요구사항 분석
자료 흐름도(DFD) (=자료 흐름 그래프, 버블 차트) : 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
프로세스 : 자료를 변환시키는 시스템의 한 부분(처리 과정)을 나타내며 처리, 기능, 변환, 버블이라고 함. 원이나 둥근 사각형으로 표시하고 그 안에 프로세스 이름을 기입
자료 흐름 : 자료의 이동(흐름)이나 연관관계를 나타냄. 화살표 위에 자료의 이름을 기입
자료 저장소 : 시스템에서의 자료 저장소(파일, 데이터베이스)를 나타냄. 도형 안에 자료 저장소 이름을 기입
단말 : 시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고 출력 데이터를 받음(정보의 생산자와 소비자). 도형 안에 이름을 기입

6. 요구사항 확인 기법

요구사항 개발 과정을 거쳐 문서화된 요구사항 관련 내용을 확인하고 검증하는 방법
요구사항 검토 : 문서화된 요구사항을 훑어보면서 확인하는 것으로 가장 일반적인 요구사항 검증 방법
프로토타이핑 : 초기 도출된 요구사항을 토대로 프로토타입을 만든 후 대상 시스템의 개발이 진행되는 동안 도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성하는 과정
프로토타입 : 상품이나 서비스가 출시되기 전에 개발 대상 시스템 또는 그 일부분을 개략적으로 만든 원형
모델 검증 : 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족시키는지 검증하는 것
인수 테스트 : 사용자가 실제로 사용될 환경에서 요구사항들이 모두 충족되는지 사용자 입장에서 확인하는 과정

7. UML(Unified Modeling Language)

시스템 분석, 설계, 구현 등 시스템 개발 과정에서 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
사물 : 모델을 구성하는 가장 중요한 기본 요소로, 다이어그램 안에서 관계가 형성될 수 있는 대상들
구조 사물 : 시스템의 개념적, 물리적 요소를 표현
행동 사물 : 시간과 공간에 따른 요소들의 행위를 표현
그룹 사물 : 요소들을 그룹으로 묶어서 표현
주해 사물 : 부가적인 설명이나 제약조건 등을 표현
관계 : 사물과 사물사이의 연관성을 표현하는 것
연관 관계 : 2개 이상의 사물이 서로 관련되어 있음
집합 관계 : 하나의 사물이 다른 사물에 포함되어 있는 관계
포함 관계 : 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
일반화 관계 : 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지
의존 관계 : 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
실체화 관계 : 사물이 할 수 있거나 해야 하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계
다이어그램 : 사물과 관계를 도형으로 표현한 것
정적 모델링 : 사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적인 구조를 표현한 것(구조적 다이어그램 사용)
동적 모델링 : 시스템의 내부 구성 요소들의 상태가 시간의 흐름에 따라 변화하는 과정과 변화하는 과정에서 발생하는 상호 작용을 표현한 것(행위 다이어그램 사용)

8. 구조적 다이어그램

클래스 다이어그램 :클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현
클래스 : 각각의 객체들이 갖는 속성과 오퍼레이션(동작)을 표현, 일반적으로 3개의 구획으로 나눠 클래스의 이름, 속성, 오퍼레이션을 표기
속성 : 클래스의 상태나 정보를 표현
오퍼레이션(연산) : 클래스가 수행할 수 있는 동작으로, 함수(메소드)라고도 함
제약조건 : 속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면 이를 적음
관계 : 클래스와 클래스 사이의 연관성을 표현
객체 다이어그램 : 클래스에 속한 사물(객체)들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현
컴포넌트 다이어그램 : 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현
배치 다이어그램 : 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현
복합체 구조 다이어그램 : 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
패키지 다이어그램 : 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

9. 시퀀스 다이어그램

시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을 그림으로 표현한 것
액터: 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템
객체: 메시지를 주고받는 주체, 콜론(:)을 기준으로 앞쪽에는 객체명을 뒤쪽에는 클래스명 기술
라이프라인 : 객체가 메모리에 존재하는 기간으로, 객체 아래쪽에 점선을 그어 표현
활성 상자 : 객체가 메시지를 주고받으며 구동되고 있음을 라이프라인 상에 겹쳐 직사각형 형태로 표현
메시지: 객체가 상호 작용을 위해 주고받는 메시지
객체 소멸 : 라이프라인 상에서 객체 소멸 표시를 만나면 해당 객체는 더이상 메모리에 존재하지 않음을 의미
프레임: 다이어그램의 전체 또는 일부를 묶어 표현

10. 커뮤니케이션 다이어그램

시퀀스 다이어그램과 같이 동작에 참여하는 객체들이 주고받는 메시지를 표현하는데, 메시지뿐만 아니라 객체들 간의 연관까지 표현
링크(Link) : 객체들 간의 관계를 표현하는 데 사용 , 액터와 객체, 객체와 객체 간에 실선을 그어 표현

11. 상태 다이어그램

하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현
상태 : 객체의 상태를 둥근 사간형 안에 기술
- 시작 상태 : 속이 채워진 원(●)
- 종료 상태 : 속이 채워진 원을 둘러싼 원(⊙)
이벤트 : 조건, 외부 신호, 시간의 흐름 등 상태에 변화를 주는 현상
상태 전환 : 상태 사이의 흐름, 변화를 화살표로 표현
프레임 : 상태 다이어그램의 범위를 표현

12 유스케이스 다이어그램

개발될 시스템과 관련된 외부 요소들, 즉 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점(View)에서 표현한 것
시스템 범위 : 시스템 내부에서 수행되는 기능들을 외부 시스템과 구분하기 위해 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현
액터 : 시스템과 상호 작용을 하는 모든 외부 요소로, 사람이나 외부 시스템을 의미
유스케이스 : 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스 또는 기능을 표현한 것
관계 : 유스케이스 다이이그램에서 관계는 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있으며, 포함 관계, 확장 관계, 일반화 관계의 3종류가 있음

13. 활동 다이어그램

자료 흐름도와 유사한 것으로, 사용자의 관점(View)에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것
액션/ 액티비티
액션 : 더 이상 분해할 수 없는 단일 작업
액티비티 : 몇 개의 액션으로 분리될 수 있는 작업
노드
시작 노드 : 액션이나 액티비티가 시작됨을 의미
종료 노드 : 액티비티 안의 모든 흐름이 종료됨을 의미
조건(판단) 노드 : 조건에 따라 제어의 흐름이 분리됨을 표현
병합 노드 : 여러 경로의 흐름이 하나로 합쳐짐을 표현
포크 노드 : 액티비티의 흐름이 분리되어 수행됨을 표현
조인 노드 : 분리되어 수행되던 액티비티의 흐름이 다시 합쳐짐을 표현
스윔레인 : 액티비티 수행을 담당하는 주체를 구분

블록가리기

밑줄가리기

요약가리기

2020-07-15 17:21 시에 저장한 글입니다.

1. 현행 시스템 파악 절차

2. 개발 기술 환경

3. 요구사항 유형

4. 요구사항 개발 프로세스

5. 요구사항 분석 기법

6. 요구사항 확인 기법

7. UML(Unified Modeling Language)

8. 구조적 다이어그램

9. 시퀀스 다이어그램

10. 커뮤니케이션 다이어그램

11. 상태 다이어그램

12 유스케이스 다이어그램

13. 활동 다이어그램